8.2.1  Semantic Modelling of Real-World Objects

Real-world objects are represented by geographic features according to the definition in ISO 19109. Geographic features of the same type (e.g. buildings, roads) are modelled by corresponding feature types that are represented as classes in the Conceptual Model (CM). The objects within a 3D city model are instances of the different feature types.

In order to distinguish and reference individual objects, each object has unique identifiers. In the CityGML 3.0 CM, each geographic feature has the mandatory featureID and an optional identifier property. The featureID is used to distinguish all objects and possible multiple versions of the same real-world object. The identifier is identical for all versions of the same real-world object and can be used to reference specific objects independent from their actual object version. The featureID is unique within the same CityGML dataset, but it is generally recommended to use globally unique identifiers like UUID values or identifiers maintained by an organization such as a mapping agency. Providing globally unique and stable identifiers for the identifier attribute is recommended. This means these identifiers should remain stable over the lifetime of the real-world object.

CityGML feature types typically have a number of spatial and non-spatial properties (also called attributes) as well as relationships with other feature or object types. Note that a single CityGML object can have different spatial representations at the same time. For example, different geometry objects representing the feature’s geometry in different levels of detail or as different spatial abstractions.

Many attributes have simple, scalar values like a number or a character string. However, some attributes are complex. They do not just have a single property value. In CityGML the following types of complex attributes occur:

• Qualified attribute values: For example, a measure consists of the value and a reference to the unit of measure, or e.g. for relative and absolute height levels the reference level has to also be named.

• Code list values: A code list is a form of enumeration where the valid values are defined in a separate register. The code list values consist of a link or identifier for the register as well as the value from that register which is being used.

• Attributes consisting of a tuple of different fields and values: For example, addresses, space occupancy, and others

• Attribute value consisting of a list of numbers: For example, representing coordinate lists or matrices

In order to support feature history, CityGML 3.0 introduces bitemporal timestamps for all objects. In CityGML 2.0, the attributes creationDate and terminationDate are supported. These refer to the time period in which a specific version of an object is an integral part of the 3D city model. In 3.0, all features can now additionally have the attributes validFrom and validTo. These represent the lifespan a specific version of an object has in the real-world. Using these two time intervals a CityGML dataset could be queried both for how did the city look alike at a specific point in time as well as how did the city model look at that time.

The combination of the two types of feature identifiers and bitemporal timestamps enables encoding not only the current version of a 3D city model, but also the model’s entire history can be represented in CityGML and possibly exchanged within a single file.

8.2.2  Class Hierarchy and Inheritance of Properties and Relations

In CityGML, the specific feature types like Building, Tunnel, or WaterBody are defined as subclasses of more general higher-level classes. Hence, feature types build a hierarchy along specialization / generalization relationships where more specialized feature types inherit the properties and relationships of all their superclasses along the entire generalization path to the topmost feature type AnyFeature.

Note: A superclass is the class from which subclasses can be created.

8.2.3  Relationships between CityGML objects

In CityGML, objects can be related to each other and different types of relations are distinguished. First of all, complex objects like buildings or transportation objects typically consist of parts. These parts are individual features of their own, and can even be further decomposed. Therefore, CityGML objects can form aggregation hierarchies. Some feature types are marked in the conceptual model with the stereotype «TopLevelFeatureType». These constitute the main objects of a city model and are typically the root of an aggregation hierarchy. Only top-level features are allowed as direct members of a city model. The information about which feature types belong to the top level is required for software packages that want to filter imports, exports, and visualizations according to the general type of a city object (e.g. only show buildings, solitary vegetation objects, and roads). CityGML Application Domain Extensions should also make use of this concept, such that software tools can learn from inspecting their conceptual schema what are the main, i.e. the top-level, feature types of the extension.

Some relations in CityGML are qualified by additional parameters, typically to further specify the type of relationship. For example, a relationship can be qualified with a URI pointing to a definition of the respective relation type in an Ontology. Qualified relationships are used in CityGML, among others, for:

• General relationships between features – association relatedTo between city objects,

• User-defined aggregations using CityObjectGroup. This relation allows also for recursive aggregations,

• External references – linking of city objects with corresponding entities from external resources like objects in a cadastre or within a BIM dataset.

The CityGML CM contains many relationships that are specifically defined between certain feature types. For example, there is the boundary relationship from 3D volumetric objects to its thematically differentiated 3D boundary surfaces. Another example is the generalizesTo relation between feature instances that represent objects on different generalisation levels.

In the CityGML 3.0 CM there are new associations to express topologic, geometric, and semantic relations between all kinds of city objects. For example, information that two rooms are adjacent or that one interior building installation (like a curtain rail) is overlapping with the spaces of two connected rooms can be expressed. The CM also enables documenting that two wall surfaces are parallel and two others are orthogonal. Also distances between objects can be represented explicitly using geometric relations. In addition to spatial relations logical relations can be expressed.

8.2.4  Definition of the Semantics for all Classes, Properties, and Relations

The meanings of all elements defined in the CityGML conceptual model are normatively specified in the data dictionary in Clause 11.

8.3.1  Geometry and Topology

Spatial properties of all CityGML feature types are represented using the geometry classes defined in ISO 19107. Spatial representations can have 0-, 1-, 2-, or 3-dimensional extents depending on the respective feature type and Levels of Detail (LOD; the LOD concept is discussed in 8.4.4 and [geometry-lod-section]). With only a few exceptions, all geometries must use 3D coordinate values. Besides primitive geometries like single points, curves, surfaces, and solids, CityGML makes use of different kinds of aggregations of geometries like spatial aggregates (MultiPoint, MultiCurve, MultiSurface, MultiSolid) and composites (CompositeCurve, CompositeSurface, CompositeSolid). Volumetric shapes are represented in ISO 19107 according to the so-called Boundary Representation (B-Rep, for explanation see [Foley2002]) only.

The CityGML Conceptual Model does not put any restriction on the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS). However, an encoding may restrict the usage of geometry types. For example, curved lines like B-splines or clothoids, or curved surfaces like NURBS could be disallowed by explicitly defining null encodings for these concepts in the encoding specification (c.f. 8.1 above).

Note that the conceptual schema of ISO 19107 allows composite geometries to be defined by a recursive aggregation for every primitive type of the corresponding dimension. This aggregation schema allows the definition of nested aggregations (hierarchy of components). For example, a building geometry (CompositeSolid) can be composed of the house geometry (CompositeSolid) and the garage geometry (Solid), while the house’s geometry is further decomposed into the roof geometry (Solid) and the geometry of the house body (Solid). This is illustrated in Figure 5.

Figure 5 — Recursive aggregation of objects and geometries in CityGML (graphic: IGG Uni Bonn).

While the CityGML Conceptual Model does not employ the topology classes from ISO 19107, topological relations between geometries can be established by sharing geometries (typically parts of the boundary) between different geometric objects. One part of real-world space can be represented only once by a geometry object and is referenced by all features or more complex geometries which are defined or bounded by this geometry object. Thus redundancy can be avoided and explicit topological relations between parts are maintained.

Basically, there are three cases for sharing geometries:

• First, two different semantic objects may be spatially represented by the same geometry object. For example, if a foot path is both a transportation feature and a vegetation feature, the surface geometry defining the path is referenced by both the transportation object and by the vegetation object.

• Second, a geometry object may be shared between a feature and another geometry. For example, a geometry defining a wall of a building may be referenced twice: By the solid geometry defining the geometry of the building, and by the wall feature.

• Third, two geometries may reference the same geometry, which is in the boundary of both. For example, a building and an adjacent garage may be represented by two solids. The surface describing the area where both solids touch may be represented only once and it is referenced by both solids. As it can be seen from Figure 5, this requires partitioning of the respective surfaces.

In general, B-Rep only considers visible surfaces. However, to make topological adjacency explicit and to allow the possibility of deletion of one part of a composed object without leaving holes in the remaining aggregate, touching elements are included. Whereas touching is allowed, permeation of objects is not in order to avoid the multiple representation of the same space.

Another example of sharing geometry objects that are members of the boundaries in different higher-dimensional geometry objects is the sharing of point geometries or curve geometries, which make up the outer and inner boundaries of a polygon. This means that each point is only represented once, and different polygons could reference this point geometry. The same applies to the representation of curves for transportation objects like roads, whose end points could be shared such as between different road segments to topologically connect them.

Note that the use of topology in CityGML datasets by sharing geometries is optional. Furthermore, an encoding of the CityGML conceptual model might restrict the usage of shared geometries. For example, it might only be allowed to share identical (support) points from different 3D polygons or only entire polygons can be shared between touching solids (like shown in Figure 5).

8.3.2  Prototypic Objects / Scene Graph Concepts

In CityGML, objects of equal shape like trees and other vegetation objects, traffic lights and traffic signs can be represented as prototypes which are instantiated multiple times at different locations (see Figure 6). The geometry of prototypes is defined in local coordinate systems. Every instance is represented by a reference to the prototype, a base point in the world coordinate reference system (CRS) and a transformation matrix that facilitates scaling, rotation, and translation of the prototype. The principle is adopted from the concept of scene graphs used in computer graphics standards. Since the ISO 19107 geometry model does not provide support for scene graph concepts, the CityGML class ImplicitGeometry has been introduced (for further description see [geometry-lod-section]). The prototype geometry can be represented using ISO 19107 geometry objects or by referencing an external file containing the geometry in another data format.

Figure 6 — Examples of prototypic shapes (source: Rheinmetall Defence Electronics).

8.3.3  Point Cloud Representation

In addition to the spatial representations defined in the Core module, the geometry of physical spaces and of thematic surfaces can now also be provided by 3D point clouds using MultiPoint geometry. This allows, for example, spatially representing the building hull, a room within a building or a single wall surface just by a point cloud. All thematic feature types including transportation objects, vegetation, city furniture, etc. can also be spatially represented by point clouds. In this way, the ClearanceSpace of a road or railway could, for instance, be modelled directly from the result of a mobile laser scanning campaign. Point clouds can either be included in a CityGML dataset or just reference an external file of some common types such as LAS or LAZ.

8.3.4  Coordinate Reference Systems (CRS)

CityGML is about 3D city and landscape models. This means that nearly all geometries use 3D coordinates, where each single point and also the points defining the boundaries of surfaces and solids have three coordinate values (x,y,z) each. Coordinates always have to be given with respect to a coordinate reference system (CRS) that relates them unambiguously with a specific position on the Earth. In contrast to CAD or BIM, each 3D point is absolutely georeferenced, which makes CityGML especially suitable to represent geographically large extended structures like airports, railways, bridges, dams, where the Earth curvature has a significant effect on the object’s geometry (for further explanations see [Kaden2017]).

In most CRS, the (x,y) coordinates refer to the horizontal position of a point on the Earth’s surface. The z coordinate typically refers to the vertical height over (or under) the reference surface. Note that depending on the chosen CRS, x and y may be given as angular values like latitude and longitude or as distance values in meters or feet. According to ISO 19111, numerous 3D CRS can be used. This includes global as well as national reference systems using geocentric, geodetic, or projected coordinate systems.

8.4.1  Spaces and Space Boundaries

In the CityGML 3.0 Conceptual Model, a clear semantic distinction of spatial features is introduced by mapping all city objects onto the semantic concepts of spaces and space boundaries. A Space is an entity of volumetric extent in the real world. Buildings, water bodies, trees, rooms, and traffic spaces are examples for such entities with volumetric extent. A Space Boundary is an entity with areal extent in the real world. Space Boundaries delimit and connect Spaces. Examples are the wall surfaces and roof surfaces that bound a building, the water surface as boundary between the water body and air, the road surface as boundary between the ground and the traffic space, or the digital terrain model representing the space boundary between the over- and underground space.

To obtain a more precise definition of spaces, they are further subdivided into physical spaces and logical spaces. Physical spaces are spaces that are fully or partially bounded by physical objects. Buildings and rooms, for instance, are physical spaces as they are bounded by walls and slabs. Traffic spaces of roads are physical spaces as they are bounded by road surfaces against the ground. Logical spaces, in contrast, are spaces that are not necessarily bounded by physical objects, but are defined according to thematic considerations. Depending on the application, logical spaces can also be bounded by non-physical, i.e. virtual boundaries, and they can represent aggregations of physical spaces. A building unit, for instance, is a logical space as it aggregates specific rooms to flats, the rooms being the physical spaces that are bounded by wall surfaces, whereas the aggregation as a whole is being delimited by a virtual boundary. Other examples are city districts which are bounded by virtual vertically extruded administrative boundaries, public spaces vs. Security zones in airports, or city zones with specific regulations stemming from urban planning. The definition of physical and logical spaces and of corresponding physical and virtual boundaries is in line with the discussion in [[Smith2000]] on the difference between bona fide and fiat boundaries to bound objects. Bona fide boundaries are physical boundaries; they correspond to the physical boundaries of physical spaces in the CityGML 3.0 CM. In contrast, fiat boundaries are man-made boundaries. They are equivalent to the virtual boundaries of logical spaces.

Physical spaces, in turn, are further classified into occupied spaces and unoccupied spaces. Occupied spaces represent physical volumetric objects that occupy space in the urban environment. Examples for occupied spaces are buildings, bridges, trees, city furniture, and water bodies. Occupying space means that some space is blocked by these volumetric objects. For instance, the space blocked by the building in Figure 7 cannot be used any more for driving through this space or placing a tree on that space. In contrast, unoccupied spaces represent physical volumetric entities that do not occupy space in the urban environment, i.e. no space is blocked by these volumetric objects. Examples for unoccupied spaces are building rooms and traffic spaces. There is a risk of misunderstanding the term OccupiedSpace. However, we decided to use the term anyway, as it is established in the field of robotics for over three decades [[Elfes1989]]. The navigation of mobile robots makes use of a so-called occupancy map that marks areas that are occupied by matter and, thus, are not navigable for robots.

Figure 7 — Occupied and unoccupied spaces

The new space concept offers several advantages:

• In the CityGML 3.0 Conceptual Model, all geometric representations are only defined in the Core module. This makes (a) models of the thematic modules simpler as they no longer need to be associated directly with the geometry classes, and (b) implementation easier as all spatial concepts have only to be implemented once in the Core module. All thematic modules like Building, Relief, WaterBody, etc. inherit their geometric representations from the Core module.

• The space concept supports the expression of explicit topological, geometrical, and thematic relations between spaces and spaces, spaces and space boundaries, and space boundaries and space boundaries. Thus, implementing the checking of geometric-topological consistency will become easier. That is because most checks can be expressed and performed on the CityGML Core module and then automatically applied to all thematic modules

• For the analysis of navigable spaces (e.g. to generate IndoorGML data from CityGML) algorithms can be defined on the level of the Core module. These algorithms will then work with all CityGML feature classes and also ADEs as they are derived from the Core. The same is true for other applications of 3D city models listed in [[Biljecki2015]] such as visibility analyses including shadow casting or solar irradiation analyses.

• Practitioners and developers do not see much of the space concept. That is because the space and space boundary classes are just abstract classes. Only elements representing objects from concrete subclasses such as Building, BuildingRoom, or TrafficSpace will appear in CityGML data sets.

8.4.2  Modelling City Objects by the Composition of Spaces

Semantic objects in CityGML are often composed of parts, i.e. they form multi-level aggregation hierarchies. This also holds for semantic objects representing occupied and unoccupied spaces. In general, two types of compositions can be distinguished:

1. Spatial partitioning: Semantic objects of either the space type OccupiedSpace or UnoccupiedSpace are subdivided into different parts that are of the same space type as the parent object. Examples are Buildings that can be subdivided into BuildingParts, or Buildings that are partitioned into ConstructiveElements. Buildings as well as BuildingParts and constructiveElements represent OccupiedSpaces. Similarly, Roads can be subdivided into TrafficSpaces and AuxiliaryTrafficSpaces, all objects being UnoccupiedSpaces.

2. Nesting of alternating space types: Semantic objects of one space type contain objects that are of the opposite space type as the parent object. Examples are Buildings (OccupiedSpace) that contain BuildingRooms (UnoccupiedSpace), BuildingRooms (UnoccupiedSpace) that contain Furniture (OccupiedSpace), and Roads (UnoccupiedSpace) that contain CityFurniture (OccupiedSpace). The categorization of a semantic object into occupied or unoccupied takes place at the level of the object in relation to the parent object. A building is part of a city model. Thus, in the first place the building occupies urban space within a city. As long as the interior of the building is not modelled in detail, the space covered by the building needs to be considered as occupied and only viewable from the outside. To make the building accessible inside, voids need to be added to the building in the form of building rooms. The rooms add free space to the building interior. In other words, the OccupiedSpace now contains some UnoccupiedSpace. The free space inside the building can, in turn, contain objects that occupy space again, such as furniture or installations. In contrast, roads also occupy urban space in the city. However, this space is initially unoccupied as it is accessible by cars, pedestrian, or cyclists. Adding traffic signs or other city furniture objects to the free space results in specific sections of the road becoming occupied by these objects. Thus, one can also say that occupied spaces are mostly filled with matter; whereas, unoccupied spaces are mostly free of matter and, thus, realize free spaces.

8.4.3  Rules for Surface Orientations of OccupiedSpaces and UnoccupiedSpaces

The classification of feature types into OccupiedSpace and UnoccupiedSpace also defines the semantics of the geometries attached to the respective features. For OccupiedSpaces, the attached geometries describe volumes that are (mostly) physically occupied. For UnoccupiedSpaces, the attached geometries describe (or bound) volumes that are (mostly) physically unoccupied. This also has an impact on the required orientation of the surface normal (at point P this is a vector perpendicular to the tangent plane of the surface at P) for attached thematic surfaces. For OccupiedSpaces, the normal vectors of thematic surfaces must point in the same direction as the surfaces of the outer shell of the volume. For UnoccupiedSpaces, the normal vectors of thematic surfaces must point in the opposite direction as the surfaces of the outer shell of the volume. This means that from the perspective of an observer of a city scene, the surface normals must always be directed towards the observer. In the case of OccupiedSpaces (e.g. Buildings, Furniture), the observer must be located outside the OccupiedSpace for the surface normals being directed towards the observer; whereas in the case of UnoccupiedSpaces (e.g. Rooms, Roads), the observer is typically inside the UnoccupiedSpace.

8.4.4  Levels of Detail (LOD)

The CityGML Conceptual Model differentiates four consecutive Levels of Detail (LOD 0-3), where objects become more detailed with increasing LOD with respect to their geometry. CityGML datasets can — but do not have to — contain multiple geometries for each object in different LODs simultaneously. The LOD concept facilitates multi-scale modelling; i.e. having varying degrees of spatial abstractions that are appropriate for different applications or visualizations.

The classification of real-world objects into spaces and space boundaries is solely based on the semantics of these objects and not on their used geometry type, as the CityGML 3.0 CM allows various geometrical representations for objects. A building, for instance, can be spatially represented by a 3D solid (e.g. in LOD1), but at the same time, the real-world geometry can also be abstracted by a single point, footprint or roof print (LOD0), or by a 3D mesh (LOD3). The outer shell of the building may also be semantically decomposed into wall, roof, and ground surfaces. Figure 8 shows different representations of the same real-world building object in different geometric LODs (and appearances).

Figure 8 — Representation of the same real-world building in the Levels of Detail 0-3.

The biggest changes between CityGML 3.0 and earlier versions are that:

1. LOD4 was dropped, because now all feature types can have outdoor and indoor elements in LODs 0-3 (for those city objects where it makes sense like buildings, tunnels, or bridges). This means that the outside shell such as of a building, could be spatially represented in LOD2 and the indoor elements like rooms, doors, hallways, stairs etc. in LOD1. CityGML can now be used to represent building floor plans, which are LOD0 representations of building interiors (cf. [konde2018]). It is even possible to model the outside shell of a building in LOD1, while representing the interior structure in LOD2 or 3. Figure 9 shows different indoor/outdoor representations of a building. Details on the changes to the CityGML LOD concept are provided in [[L].

2. Levels of Detail are no longer associated with the degree of semantic decomposition of city objects and refer to the spatial representations only. This means that, for example, buildings can have thematic surfaces (like WallSurface, GroundSurface) also in LODs 0 and 1 and windows and doors can be represented in all LODs 0-3. In CityGML 2.0 or earlier thematic surfaces were only allowed starting from LOD2, openings like doors and windows starting from LOD3, and interior rooms and furniture only in LOD4.

3. In the CityGML 3.0 Conceptual Model the geometry representations were moved from the thematic modules to the Core module and are now associated with the semantic concepts of Spaces and Space Boundaries. This led to a significant simplification of the models of the thematic modules. Since all feature types in the thematic modules are defined as subclasses of the space and space boundary classes, they automatically inherit the geometry classes and, thus, no longer require direct associations with them. This also led to a harmonized LOD representation over all CityGML feature types.

4. If new feature types are defined in Application Domain Extensions (ADEs) based on the abstract Space and Space Boundary classes from the Core module, they automatically inherit the spatial representations and the LOD concept.

Figure 9 — Floor plan representation (LOD0) of a building (left), combined LOD2 indoor and outdoor representation (right). Image adopted from [L.

Spaces and all its subclasses like Building, Room, and TrafficSpace can now be spatially represented by single points in LOD0, multi-surfaces in LOD0/2/3, solids in LOD1/2/3, and multi-curves in LOD2/3. Space Boundaries and all its subclasses such as WallSurface, LandUse, or Relief can now be represented by multi-surfaces in LOD0/2/3 and as multi-curves in LOD2/3. See [geometry-lod-section] for further details on the different Levels of Detail.

8.4.5  Closure Surfaces

Objects, which are not spatially represented by a volumetric geometry, must be virtually closed in order to compute their volume (e.g. pedestrian underpasses or airplane hangars). They can be sealed using a specific type of space boundary called a ClosureSurface. These are virtual surfaces. They are used when a closed surface is needed to compute volumes or perform similar 3D operations. Since they do not actually exist, they are neglected when they are not needed or not appropriate. For example, ClosureSurfaces would not be used in visualizations.

The concept of ClosureSurface can also be employed to model the entrances of subsurface objects. Those objects like tunnels or pedestrian underpasses have to be modelled as closed solids in order to compute their volume. An example would be for use in flood simulations. The entrances to subsurface objects also have to be sealed to avoid holes in the digital terrain model (see Figure 10). However, in close-range visualizations the entrance should be treated as open. Thus, closure surfaces are an adequate way to model those entrances.

Figure 10 — Closure surfaces to seal open structures. Passages are subsurface objects (left). The entrance is sealed by a virtual ClosureSurface feature, which is both part of the DTM and the subsurface object (right) (graphic: IGG Uni Bonn).

8.4.6  Terrain Intersection Curves

An important issue in city modelling is the integration of 3D objects and the terrain. Problems arise if 3D objects float over or sink into the terrain. This is particularly the case when terrains and 3D objects in different LODs are combined, when the terrain and 3D models are updated independently from each other, or when they come from different data providers [[Kolbe2003]]. To overcome this problem, the TerrainIntersectionCurve (TIC) of a 3D object is introduced. These curves denote the exact position where the terrain touches the 3D object (see Figure 11). TICs can be applied to all CityGML feature types that are derived from AbstractPhysicalSpace such as buildings, bridges, tunnels, but also city furniture, vegetation, and generic city objects.

If, for example, a building has a courtyard, the TIC consists of two closed rings: One ring representing the courtyard boundary, and one which describes the building’s outer boundary. This information can be used to integrate the building and a terrain by ‘pulling up’ or ‘pulling down’ the surrounding terrain to fit the TerrainIntersectionCurve. The digital terrain model (DTM) may be locally warped to fit the TIC. By this means, the TIC also ensures the correct positioning of textures or the matching of object textures with the DTM. Since the intersection with the terrain may differ depending on the LOD, a 3D object may have different TerrainIntersectionCurves for all LODs.

Figure 11 — TerrainIntersectionCurve for a building (left, black) and a tunnel object (right, red). The tunnel’s hollow space is sealed by a triangulated ClosureSurface (graphic: IGG Uni Bonn).

8.4.7  Coherent Semantical-Geometrical Modelling

An important design principle for CityGML is the coherent modelling of semantic objects and their spatial representations. At the semantic level, real-world entities are represented by features, such as buildings, walls, windows, or rooms. The description also includes attributes, relations and aggregation hierarchies (part-whole-relations) between features. Thus the part-of-relationship between features can be derived at the semantic level only, without considering geometry. However, at the spatial level, geometry objects are assigned to features representing their spatial location, shape, and extent. So the model consists of two hierarchies: The semantic and the geometrical in which the corresponding objects are linked by relationships (cf. [stadler2007]). The advantage of this approach is that it can be navigated in both hierarchies and between both hierarchies arbitrarily, for answering thematic and/or geometrical queries or performing analyses.

If both hierarchies exist for a specific object, they must be coherent (i.e. it must be ensured that they match and fit together). For example, if a building is semantically decomposed into wall surfaces, roof surfaces and so forth, the polygons representing these thematic surfaces (in a specific LOD) must be part of the solid geometry representing the entire building (for the same LOD).

8.6.1  Versioning and Histories

As described in 8.2.1, the bitemporal timestamps of all CityGML feature types allow representing the evolution of the real city and its model over time. The new Versioning module extends this concept by the possibility of representing multiple, concurrent versions of the city model. For that purpose, the module defines two new feature types: 1) Version, which can be used to explicitly define named states of the 3D city model and denote all the specific versions of objects belonging to such states. 2) VersionTransition, which allows to explicitly link different versions of the 3D city model by describing the reason of change and the modifications applied. Details on the versioning concept are given in [[Chaturvedi2015]].

This approach not only facilitates the explicit representation of different city model versions, but also allows distinguishing and referring to different versions of city objects in an interoperable exchange format. All object versions could be stored and exchanged within a single dataset. Software systems could use such a dataset to visualize and work with the different versions simultaneously. The conceptual model also takes into account the management of multiple histories or multiple interpretations of the past of a city, which is required when looking at historical city developments and for archaeological applications. In addition, the Versioning module supports collaborative work. All functionality to represent a tree of workspaces as version control systems like git or SVN is provided. The Versioning module handles versions and version transitions as feature types, which allows the version management to be completely handled using the standard OGC Web Feature Service [[Vretanos2010]]. No extension of the OGC Web Feature Service standard is required to manage the versioning of city models.

8.6.2  Dynamizers: Using Time-Series Data for Object Attributes

The new Dynamizer module improves the usability of CityGML for different kinds of simulations as well as to facilitate the integration of devices from the Internet-of-Things (IoT) like sensors with 3D city models. Both, simulations and sensors provide dynamic variations of some measured or simulated properties such as the electricity consumption of a building or the traffic density within a road segment. The variations of the value are typically represented using time-series data. The data sources of the time-series data could be either sensor observations (e.g. from a smart meter), pre-recorded load profiles (e.g. from an energy company), or the results of some simulation run.

Figure 12 — Dynamizers link timeseries data coming from different sources to specific properties of individual city objects.

As shown in Figure 12, Dynamizers serve three main purposes:

1. Dynamizer is a data structure to represent dynamic values in different and generic ways. Such dynamic values may be given by (1) tabulation of time/value pairs using its AtomicTimeseries class, (2) patterns of time/value pairs based on statistical rules using its CompositeTimeseries class, and (3) retrieving observations directly from external sensor/IoT services using its SensorConnection class. The values can be obtained from sensor services such as the OGC Sensor Observation Service or OGC SensorThings API, simulation specific databases, and also external files such as CSV or Excel sheets.

2. Dynamizer delivers a method to enhance static city models by adding dynamic property values. A Dynamizer references a specific property (e.g. spatial, thematic or appearance properties) of a specific object within a 3D city model providing dynamic values overriding the static value of the referenced object attribute.

3. Dynamizer objects establish explicit links between sensor/observation data and the respective properties of city model objects that are measured by them. By making such explicit links with city object properties, the semantics of sensor data become implicitly defined by the city model.

Dynamizers are used to inject dynamic variations of city object properties into an otherwise static representation. The advantage in following such an approach is that it allows only selected properties of city models to be made dynamic. If an application does not support dynamic data, the application simply does not allow/include these special types of features.

Dynamizers have already been implemented as an Application Domain Extension (ADE) for CityGML 2.0 and were employed in the OGC Future City Pilot Phase 1. More details about Dynamizers are given in [[Chaturvedi2017]].

9.1.1  Construction

The ADE data types provided for the Construction module are illustrated in [construction-uml-ade-types].

requirements/requirements_class_construction

requirements/construction/REQ_construction_Classes requirements/construction/REQ_construction_Boundaries

Table 3

9.1.2  Class Definitions

Table 4 — Classes used in Construction

Table 5 — Enumerated Classes used in Construction

9.2.1  Dynamizer

The ADE data types provided for the Dynamizer module are illustrated in [dynamizer-uml-ade-types].

requirements/requirements_class_dynamizer

requirements/dynamizer/REQ_dynamizer_Classes requirements/dynamizer/REQ_dynamizer_Boundaries

Table 6

9.2.2  Class Definitions

Table 7 — Classes used in Dynamizer

Table 8 — Enumerated Classes used in Dynamizer

9.3.1  PointCloud

The ADE data types provided for the PointCloud module are illustrated in [pointcloud-uml-ade-types].

requirements/requirements_class_pointcloud

requirements/pointcloud/REQ_pointcloud_Classes requirements/pointcloud/REQ_pointcloud_Boundaries

Table 9

9.3.2  Class Definitions

Table 10 — Classes used in PointCloud

9.4.1  Versioning

The ADE data types provided for the Versioning module are illustrated in [versioning-uml-ade-types].

requirements/requirements_class_versioning

requirements/versioning/REQ_versioning_Classes requirements/versioning/REQ_versioning_Boundaries

Table 11

9.4.2  Class Definitions

Table 12 — Classes used in Versioning

Table 13 — Enumerated Classes used in Versioning

9.5.1  Appearance

The ADE data types provided for the Appearance module are illustrated in [appearance-uml-ade-types].

requirements/requirements_class_appearance

requirements/appearance/REQ_appearance_Classes requirements/appearance/REQ_appearance_Boundaries

Table 14

9.5.2  Class Definitions

Table 15 — Classes used in Appearance

Table 16 — Enumerated Classes used in Appearance

9.6.1  Bridge

The ADE data types provided for the Bridge module are illustrated in [bridge-uml-ade-types].

requirements/requirements_class_bridge

requirements/bridge/REQ_bridge_Classes requirements/bridge/REQ_bridge_Boundaries

Table 17

9.6.2  Class Definitions

Table 18 — Classes used in Bridge

9.7.1  Building

The ADE data types provided for the Building module are illustrated in [building-uml-ade-types].

requirements/requirements_class_building

requirements/building/REQ_building_Classes requirements/building/REQ_building_Boundaries

Table 19

9.7.2  Class Definitions

Table 20 — Classes used in Building

9.8.1  CityFurniture

The ADE data types provided for the CityFurniture module are illustrated in [cityfurniture-uml-ade-types].

requirements/requirements_class_cityfurniture

requirements/cityfurniture/REQ_cityfurniture_Classes requirements/cityfurniture/REQ_cityfurniture_Boundaries

Table 21

9.8.2  Class Definitions

Table 22 — Classes used in CityFurniture

9.9.1  CityObjectGroup

The ADE data types provided for the CityObjectGroup module are illustrated in [cityobjectgroup-uml-ade-types].

requirements/requirements_class_cityobjectgroup

requirements/cityobjectgroup/REQ_cityobjectgroup_Classes requirements/cityobjectgroup/REQ_cityobjectgroup_Boundaries

Table 23

9.9.2  Class Definitions

Table 24 — Classes used in CityObjectGroup

9.10.1  Core

The ADE data types provided for the Core module are illustrated in [core-uml-ade-types].

requirements/requirements_class_core

requirements/core/REQ_core_Classes requirements/core/REQ_core_Boundaries

Table 25

9.10.2  Class Definitions

Table 26 — Classes used in Core

Table 27 — Enumerated Classes used in Core

9.11.1  Generics

The ADE data types provided for the Generics module are illustrated in [generics-uml-ade-types].

requirements/requirements_class_generics

requirements/generics/REQ_generics_Classes requirements/generics/REQ_generics_Boundaries

Table 28

9.11.2  Class Definitions

Table 29 — Classes used in Generics

9.12.1  LandUse

The ADE data types provided for the LandUse module are illustrated in [landuse-uml-ade-types].

requirements/requirements_class_landuse

requirements/landuse/REQ_landuse_Classes requirements/landuse/REQ_landuse_Boundaries

Table 30

9.12.2  Class Definitions

Table 31 — Classes used in LandUse

9.13.1  Relief

The ADE data types provided for the Relief module are illustrated in [relief-uml-ade-types].

requirements/requirements_class_relief

requirements/relief/REQ_relief_Classes requirements/relief/REQ_relief_Boundaries

Table 32

9.13.2  Class Definitions

Table 33 — Classes used in Relief

9.14.1  Transportation

The ADE data types provided for the Transportation module are illustrated in [transportation-uml-ade-types].

requirements/requirements_class_transportation

requirements/transportation/REQ_transportation_Classes requirements/transportation/REQ_transportation_Boundaries

Table 34

9.14.2  Class Definitions

Table 35 — Classes used in Transportation

Table 36 — Enumerated Classes used in Transportation

9.15.1  Tunnel

The ADE data types provided for the Tunnel module are illustrated in [tunnel-uml-ade-types].

requirements/requirements_class_tunnel

requirements/tunnel/REQ_tunnel_Classes requirements/tunnel/REQ_tunnel_Boundaries

Table 37

9.15.2  Class Definitions

Table 38 — Classes used in Tunnel

9.16.1  Vegetation

The ADE data types provided for the Vegetation module are illustrated in [vegetation-uml-ade-types].

requirements/requirements_class_vegetation

requirements/vegetation/REQ_vegetation_Classes requirements/vegetation/REQ_vegetation_Boundaries

Table 39

9.16.2  Class Definitions

Table 40 — Classes used in Vegetation

9.17.1  WaterBody

The ADE data types provided for the WaterBody module are illustrated in [waterbody-uml-ade-types].

requirements/requirements_class_waterbody

requirements/waterbody/REQ_waterbody_Classes requirements/waterbody/REQ_waterbody_Boundaries

Table 41

9.17.2  Class Definitions

Table 42 — Classes used in WaterBody

10.1.1  Construction

Table 43

10.1.2  Classes

Table 44

Table 48

Table 52

Table 56

Table 60

Table 64

Table 68

Table 72

Table 76

Table 80

Table 84

Table 88

Table 92

Table 96

Table 100

Table 104

Table 108

Table 112

Table 116

Table 120

Table 124

Table 128

Table 132

Table 136

Table 140

Table 144

Table 148

Table 152

Table 156

Table 160

Table 164

10.2.1  Dynamizer

Table 168

10.2.2  Classes

Table 169

Table 173

Table 177

Table 181

Table 185

Table 189

Table 193

Table 197

Table 201

Table 205

Table 209

10.3.1  PointCloud

Table 213

10.3.2  Classes

Table 214

10.4.1  Versioning

Table 218

10.4.2  Classes

Table 219

Table 223

10.5.1  Appearance

Table 227

10.5.2  Classes

Table 228

Table 232

Table 236

Table 240

Table 244

Table 248

Table 252

Table 256

10.6.1  Bridge

Table 260

10.6.2  Classes

Table 261

Table 265

Table 269

Table 273

Table 277

Table 281

Table 285

Table 289

Table 293

Table 297

Table 301

Table 305

Table 309

Table 313

Table 317

Table 321

Table 325

Table 329

Table 333

Table 337

Table 341

Table 345

10.7.1  Building

Table 349

10.7.2  Classes

Table 350

Table 354

Table 358

Table 362